The present invention relates to methods and apparatus for processing data within a computer network. More specifically, it relates to mechanisms for handling data generated by applications that use embedded addresses while such data is traversing a Network Address Translation (NAT) device or a like device.
For a particular computer to communicate with other computers or web servers within a network (e.g., the Internet), the particular computer must have a unique IP (Internet Protocol) address. IP protocol version 4 specifies 32 bits for the IP address, which theoretically gives about 4,294,967,296 unique IP addresses. However, there are actually only between 3.2 and 3.3 billion available IP addresses since the addresses are separated into classes and set aside for multicasting, testing and other special uses. With the explosion of the Internet, the number of IP addresses is not enough to give each computer a unique IP address.
One solution for addressing computers with the limited number of IP addresses is referred to as network address translation (NAT). NAT allows an intermediary device (e.g., computer, router or switch) located between the Internet network and a local network to serve as an agent for a group of local computers. A small range of IP addresses or a single IP address is assigned to represent the group of local computers. Each computer within the local group is also given a local IP address that is only used within that local group. However, the group's local IP addresses may duplicate IP address that are used outside of the local network. When a local computer attempts to communicate with a computer outside the local network, the intermediary device matches the local computer's local IP address (and port) to one of the intermediary device's assigned IP addresses (and ports). The intermediary device then replaces the local computer's local address (and port) with the matched assigned IP address (and port). This matched assigned IP address (and port) is then used to communicate between the local computer and the outside computer. Thus, NAT techniques allow IP address to be duplicated across local networks.
Another solution to the lack of available IP addresses is to redesign the address format to allow for more possible IP addresses. The recent introduction of IPv6 provides 128 bits for the IP address, as compared with IPv4 which provides 32 bits for the IP address. However, until all network devices and computers are converted to IPv6, it is still necessary to allow an existing IPv4 device to communicate with an IPv6 device. One popular method that allows IPv4 to IPv6 communication is referred to as protocol translation (NAT-PT). The IP addresses are converted by NAT-PT from one protocol to another protocol (e.g., IPv4 to IPv6 or vice versa) or, more generally, from an external protocol to an internal protocol. In addition to the IP addresses, the NAT-PT also converts any relevant IPv4 or IPv6 information during a protocol translation.
In addition to IP addresses, a packet may also contain address(es), as well as other protocol specific fields, embedded in the payload that require translation. Particular applications may embed address(es) in the payload for various application specific purposes. A current approach for supporting applications which embed IP addresses in the payload in a NAT environment is to add application-specific knowledge (referred to as an application level gateway or ALG) within the NAT device itself. This approach is described in detail in the Internet Engineering Task Force's Request for Comments document, having RFC 2663, entitled “IP Network Address Translator (NAT) Terminology and Considerations” by P. Srisuresh and M. Holdrege of Lucent Technologies (August 1999), which document is incorporated herein by reference in its entirety.
A NAT device may be configured with various ALG's which correspond to different applications which embed addresses using different formats in the payload. That is, an ALG must be designed for each specific format of the payload so as to be able to locate one or more addresses embedded in the payload by a specific type of application, such as a DNS (domain name server) application.
Other approaches include NAT traversal mechanisms to avoid the problem by allowing a NATted endpoint to “discover” its external address as described in Internet Engineering Task Force's Request for Comments document, having RFC 3489, entitled “Simple Traversal of User Datagram Protocol (UDP) Through Network Address Translators (NATs)” by J. Rosenberg et al. of Cisco Systems, Inc. (March 2003), which document is incorporated herein by reference in its entirety. Another approach allows the endpoint to request an external address or to request it in advance, which is described in (1) the Internet Engineering Task Force's Request for Comments document, having RFC 3304, entitled “Middlebox Communications (midcom) Protocol Requirements” by R. P. Swale et al. of Cisco Systems, Inc. (August 2002) and (2) the Internet Engineering Task Force's Request for Comments document, having RFC 3303, entitled “Middlebox Communications Architecture and Framework” by P. Srisuresh et al. (August 2002), which documents are incorporated herein by reference in their entirety.
Although conventional approaches for NAT ALG with packets utilizing addresses as part of the payload work adequately under some circumstances, under other situations these approaches have significant disadvantages. Aside from the complexity and expense of these approaches (e.g., supporting stateful inspection for a diversity of protocols and protocol versions in the ALG configured NAT devices), the embedded addresses cannot be handled at all when they are encrypted. Additionally, an endpoint may be configured to perform an integrity check on the data and this check may fail if the data has changed (e.g., an embedded address has been replaced with a different translated address by an ALG-NAT device.
Conventional NAT traversal mechanisms assume that the network includes NAT devices that are all supporting such. However, one or more NAT devices in the NAT traversal path may not support a NAT traversal mechanism that is being implemented to obtain an external address, for example. For instance, if a first node wishes to discover its external address, it sends a packet containing its private address through a particular NAT traversal path having one or more NAT devices. As the packet traverses through the path, the first NAT device in the path translates the private address into a translated address if the NAT device implements the currently used NAT traversal mechanism. The other NAT devices in the path also each translate the current address for the first node into another translated address for such first node if they support this NAT traversal mechanism.
If any of the NAT devices fail to support such NAT traversal mechanism, the first node's address will not be translated correctly as it travels down the NAT traversal path (i.e., one of the NAT devices will not translate the first node's address. Thus, the first node will fail to obtain it's correct external address. The first node will also fail to be notified of such failure and the first node will merely receive no response for it's “external address” query. The first node may continue to repeatedly query without realizing that a NAT traversal failure has occurred. As a result, this process may needlessly consume valuable processing resources.
In view of the above, there is a need for improved mechanisms for discovering whether any NAT devices fail to support such NAT traversal mechanism and preferably to recover from such failure.